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A method and system for providing lists of mer 

chants that provide particular products and services to 
customers and for receiving and distributing submis- 
sions of requests for quotes from customers to mer- 
chants. The system comprises various communica- 
tions media, centralized servers, and a centralized data- 
base (hat contains merchant and customer information. 
Customers access the merchant information via a ba- 
sic transaction and transaction protocol in order to re- 
ceive a list of merchants that offer any particular prod- 
uct or service. The customer then submits requests 
for quotes to each of the merchants from the list of 
merchants through the intelligent multi-media market 
and receives quotes back either directly from the mer- 
chants or through the intelligent multi-media market. 
The intelligent multi-media market identifies merchants 
through automated processes. The merchants are not 
provided exclusivity agreements to participate in the 
intelligent multi-media market, and may opt out of par- 
ticipation in the intelligent multi-media market at any 
time. 
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Technical Field 

The present invention relates to technology-based retail and wholesale 
markets, and, in particular, to a method and system for compiling lists of merchants 
for customers and for presenting requests for quotes from customers to merchants. 

Background of the Invention 

The retailing of goods and services by merchants to well-informed 
consumers, and the wholesaling of goods and services by wholesalers to merchants, by 
means of an efficient marketplace is a fundamental basis for a free market economy n 
The need for better mechanisms for informing potential retail and wholesale custcnnef^ 
of services and goods available for sale by merchants and the need for increasingHflip 
efficiency, and decreasing the costs, of individual transactions have historically 
provided some of the strongest motivations for technological development. Methods- 
for informing customers of available goods and services span an enormous range of 
technologies, from the cries of street vendors in crowded urban centers to graphical 
interactive web advertisements. Similarly, the efficiency of individual transactions 
currently spans simple barter exchange in urban markets to highly-automated 
electronic funds transfers. Although great technological and economic strides have 
been made towards increasing the flow of information to consumers and towards 
increasing the efficiency by which consumers obtain goods and services, there is still 
much room for improvement. 

Tables 1 and 2, below, summarize various characteristics of different 
types of technology-enabled markets from the perspective of customers. The types of 
technology-enabled markets for which characteristics are listed in Tables 1 and 2 
include: (1) in-person shopping; (2) shopping by mail; (3) shopping by telephone; (4) 
shopping through a buying service; (5) direct internet shopping; (6) shopping via an 
internet virtual store; (7) employing an internet-based shopping agent; (8) shopping via 
an internet-based vertical quote aggregator; and (9) shopping via an internet-based 
horizontal quote aggregator. These types of technology-based markets appear, in both 
Tables 1 and 2, in the first column entitled "Type of Shopping." Within each row of 
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Tables 1 and 2, each column, starting with the second column contains values for a 
particular characteristic applicable to the technology-enabled market listed in the first 
column. The final row in Tables 1 and 2 indicates the most desirable value for a 
particular characteristic 

Table 1, below,, includes various characteristics of. Jpchnology-enabled 
markets that are currently adequately served by at least one type of technology-enabled 
market. 

Table 1 



Type of 
Shopping 


Timelines of 
Search 


Cost of Search 


Cost of 
Inquiry 


Timeliness of 
Inquiry 


Flexibility of 
Inquiry 


In-perspri 


poor 


high 


high 


poor • 


pQor ; 


Mail 


poor 


proportional to 
breadth 


fair 


poor 


good , 


Telephone 


fair 


proportional to 
breadth 


fair 


fair/good 


fair 


Buying Service 


fair/good 


low 


low 


good 


good 


Internet Direct 


fair 


low 


low 


fair/good 


good 


Internet Virtual 
Store 


good 


low 


low 


good 


good 


Internet 

Shopping 

Agent 


fair/good 


low 


low 


good 


good - 


Internet 
Vertical Quote 
Aggregators 


fair 


low 


low 


good 


good 


Internet 

Horizontal 

Quote 

Aggregations 


fair 


low 


low 


good 


good 


Desired 
Method 


good 


low 


low 


good 


good 



The technology-enabled markets are listed in Tables 1 and 2 in the order in which the 
markets were developed, starting from the oldest markets. In general, values for the 
various characteristics of technology-enabled markets approach the most desirable 
values listed in the final row of Tables 1 and 2 as the tine since development of the 
technology-enabled markets decreases from the top of Tables 1 and 2 to the bottom of 
Tables 1 and 2. This is a rather natural result of technologies being driven by the need 
for improvement. For example, consider the first characteristic listed in Table 1, the 
timeliness with which a customer can search for merchants that provide a particular 
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good or service. The timeliness of identifying merchants by in-person shopping is 
generally quite poor. In-person shopping requires the customer to be transported 
physically to a number of different retail establishments distributed over some 
geographical area in order to identify merchants offering a particular gdid or service. . 4 
In a mail-based market, the timeliness of searching for merchants that offer a* 
particular good or service is also relatively poor. Either the customer must passively 
wait to receive mail order catalogs or advertising fliers, or the customer must send out 
inquiries and wait for the responses to the inquiries in the return mail. 

Probably the single greatest technological improvement, from the 
standpoint of customers, has been the development of the telephone. By using the 
telephone, a customer can far more quickly and immediately search a variety of retail " 
establishments for provision of a partieular good or service. .A buying servie, 
contacted by a customer via a telephone call, may further improve the timeliness of 
searching for merchants that provide a particular good or service. The buying service 
may develop pre-compiled and cross indexed lists of merchants and goods and services 
and thus take advantage of an extensive searching effort made in advance of a 
customer's need for identifying merchants that offer a particular good or service. 
Generally, a buying service employee interacts with a customer to obtain information 
about the good or service desired by a customer and various customer preferences, 
and then uses the pre-compiled list of merchants to directly contact merchants in order 
to identify one or more merchants that can offer the good or service to the customer at 
a favorable price and at favorable terms. The buying service may provide the 
customer with the list of the merchants, or may undertake management of the sale of 
the good or service to the customer. 

Nowadays, a customer may connect to the Internet via an Internet 
browser and use Internet search tools to identify and browse web sites and homepages 
that offer goods and services by merchants. However, this direct Internet market may 
be only marginally more efficient than a telephone search, depending on the types of 
goods and services desired. For certain types of goods, an Internet virtual store may 
provide quite timely return of information with respect to a particular good or service. 
The Internet virtual store may offer a variety of different brands and service providers 
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through a single set of interrelated web pages. The customer may instead employ an 
Internet-based shopping agent to search the internet for web sites that offer a particular 
good or service. Depending on the good or service sought by the customer, the 
automated searching via a shopping agent may provide a quite timely search. 

More recently, a new type of market has developed on the Internet 
through which a customer may solicit quotes from merchants for provision of a 
particular good or service. This new type of market is referred to as an "aggregator. " 
There are vertical quote aggregators that offer quote request submission to merchants 
for a particular type of good or service and horizontal quote aggregators that attempt 
to offer submission of requests for quotes from customers to merchants for a broad 
range of goods and service categories. For - l)^V vertical .and horizontal quote 
aggregators, the timeliness of the search is limited by the time required for particular 
merchants to respond to quotes. However, because the merchants have been identified 
by advance searching, the timeliness of a customer search for a particular good or 
service may be substantially better than searches conducted by a customer via more 
direct markets, such as the telephone market or direct Internet market. 

The characteristics of the various technology-enabled markets listed in- 
Table 1 include: (1) the timeliness of searching for a particular good or service; (2) the 
cost of searching for a particular good or service; (3) the costs of making an inquiry 
concerning price, availability, or other purchase parameters; (4) the" timeliness of 
making an inquiry about purchase parameters; and (5) the flexibility of purchase 
parameter inquiries. In general, the cost of searching for merchants that provide: a 
particular good or service is quite high for in-person shopping, proportional to the 
breadth of the search for mail and telephone markets, and relatively low for the more 
advanced market-enabled technologies, including Internet markets. This same trend is 
seen for the cost of purchase parameter inquiries, the timeliness of purchase parameter 
inquiries, and the flexibility with which a customer may make purchase parameter 
inquiries. The flexibility of a purchase parameter inquiry includes the ability to make 
an inquiry at various times of day, on weekends, and on holidays, and the ability to 
easily submit inquiries for varying numbers of purchase parameters. 
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Table 2 includes additional characteristics of technology-enabled 
markets for which current technology-enabled markets do not offer optimal values. 
Again, as in Table 1, the desired values for the characteristics included in Table 2 are 
shown in the first row, beneath the column headings of Table 2. The characteristics 
displayed in Table 2 include: (1) the geographical breadth of a search for provision of 
a good or service possible using a particular technology-enabled market; (2) the 
thoroughness of searching obtainable by a customer via a particular technology- 
enabled market; (3) the ease by which a customer can compare prices and other 
purchase parameters offered by various competing merchants; and (4) the degree to 
which a particular technology-enabled market provides a customer with advanced 
information and tools, such as verification of a merchants business practices and 
tracking of inquiries and requests for quotes submitted to merchants: 
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Table 2 



Type of 
shopping 


Geographical 
Breadth of Search 


Thoroughness 
of Search 


Ease of 
Comparing Prices 


Verification of 
Merchant, Tracking 
of Inquiries 


In-person 


low 


poor 


poor 


low 


Mail 


limited by available 
addresses 


poor 


poor 


low 


Telephone 


limited by available 
phone numbers 


poor 


poor/fair 


low 


Buying Service 


limited by 
exclusivity and 
diligence 


poor/fair 


poor/fair 


low 


Internet Direct 


limited by available 
web addresses 


poor 


poor/fair 


low 


Internet Virtual 
oiort; 


limited by 
exclusivity and 
resources 


poor 


poor 


low 


Internet 

Shopping 

Agent 


limited by available 
web sites and 
search agent 


fair 


poor/fair 


low 


Internet 
Vertical Quote 
Aggregators 


limited by 
exclusivity, 
diligence, resources 


poor 


fair 


low 


Internet 

Horizontal 

Quote 

Aggregators 


limited by 
exclusivity, 
diligence, resources 


poor 


fair 


low 


Desired 
Method 


high * - 


good 


good 


good 



As can be seen from Table 2, above, none of the currently-available technology- 
enabled markets provide optimal values for the characteristics listed in Table 2. In all 
cases, the geographical breadth of a customer's search is either extremely low, in the 
case of in-person shopping, or limited by one or more resources. Mail and telephone 
shopping limit the geographical breadth of the search because of limitations in 
availability of non-local telephone number listings and mail addresses as well as by 
cost. The further a given merchant is located from a customer, the more expensive, in 
general, the information exchange between the customer and the merchant via mail or 
telephone. Various internet-based markets are also limited geographically, either by. 
the availability of the Internet to merchants in different areas and of different 
technological capabilities, as well as by language barriers and by biased searching 
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methodologies. In general, none of the currently-available technology-enabled 
markets provide the customer with the ability to easily conduct thorough searches, and 
none provide the customer with an easy way to compare prices, although the internet- 
based quote aggregators do provide for price comparison between^^^merchants to 
which the quote aggregators submit quote requests. Unfortunately, the quote 
aggregators generally operate through exclusivity agreements with particular 
merchants, or require merchants to subscribe to the quote aggregator for a fee, thus 
providing the customer with a relatively small and biased pool of merchants to which 
requests for* quotes can be submitted. Finally, none of the currently-available 
technology-enabled markets provide easily accessible and high quality information 
tools, such as tools for verifying a merchant's business practices or for tracking quote 
requests after they have been submitted to particular merchants. 

Tables 3 and 4 are laid out similarly to Tables 1 and 2, respectively, 
with the exception that the characteristics included in Tables 3 and 4 relate to a 
merchant's perspective of a particular technology-enabled market. Table 3 shows 
characteristics for which at least one currently-available technology-enabled market 
provides a desirable value. As in Tables 1 and 2, the desired values for the 
characteristics in Tables 3 and 4 appear in the final row. 
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Table 3 



Type of 
Shopping 
Service 


Timeliness of 
Responding to 
Searching 
Customers 


Cost of 
Responding 
to Searching 
Customers 


Cost of 
Advertising 


Cost of Receiving 
Proportional to 
Responding to 

Inrtiitrv 
llUJUil y 


Flexibility of 
Responding to 
and Receiving 
inquiry 


In-person 


Fair/good 


high 


low/fair 


high 


low 


Mail 


poor 


high 


high 


high 


low . 


Telephone 


fair/good 


high 


low/fair 


high 


low 


Buying 


fair/good 


faii- 


high 


fair/high 


fan- 


Internet 
direct 


good 


low 


low 


fair 


high 


Internet 
virtual store 


good 


low 


low 


low 


high 


Internet 

shopping 

agent 


good 


low 


low 


N/A 


N/A 


Internet 
quote 

aggregators 


good 


. . ■ ■ m- 

low 


low 


low 


high/ # * 


Internet 

horizontal 

quote 

aggregators 


good 


low 


low 


low 


high 


Desired 
method 


good 


low 


low 


low 


high 



Table 4 shows characteristics for which no currently-available technology-enabled 
market provides a desirable value. „ 

Table 4 



Type of Shopping 


Geographical 
Reachability 


Ease of Offering 
Comparable Prices 


Tools for 
Processing Quotes 


Feedback from 
Customers. 


In-person 


low 


fair 


poor 


poor 


Mail 


limited 


fair 


poor 


poor 


Telephone 


limited 


low 


poor 


poor 


Buying service 


limited 


fair 


poor 


poor 


Internet direct 


limited 


fair 


poor 


poor 


Internet virtual 
store 


limited 


fair 


poor 


poor 


Internet shopping 
agent 


limited 


high 


poor 


poor 


Internet quote 
aggregators 


limited 


fair 


poor 


poor 


Internet horizontal 
quote aggregators 


limited 


fair 


poor 


poor 


Desired method 


high 


high 


good 


good 
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Thus, although currently-available technology-enabled markets 
adequately serve some customer and merchant needs, other merchant and customer 
needs have yet to be adequately addressed. In particular, currently-available 
technology-enabled markets provide customers with less than adequate geographical 
breadth and thoroughness of searching for merchants that provide a particular good or 
service, provide less than adequate facilities for comparing prices offered by 
merchants for particular goods and services, and provide virtually no advanced 
information tools to allow a customer to verify a merchant's business practices, peruse 
customer feedback directed to a merchant, or track inquiries submitted by the 
customer to various merchants. Similarly, currently-available technology-enabled 
markets do not adequately address the need of merchants for efficiently and broadly 
advertising goods and services, for offering comparative prices, for tools that facilitate 
processing of requests for quotes and other inquiries from customers, and for tools 
that facilitate obtaining feedback from customers. Naturally, many of these 
inadequately served needs can be addressed through ad hoc mechanisms, cost and 
labor intensive services, and other techniques, but it is most desirable for a 
technology-enabled market to provide adequate solutions for these unsatisfied 
customer and merchant needs, as well as to provide the technological advances 
provided by currently-available technology-enabled markets; 

Summary of the Invention 

The present invention provides a method and system for facilitating the 
informed selection of merchants by a customer for the provision of particular goods 
and services to the customer and for facilitating an exchange of information between 
the customer and selected merchants regarding a planned purchase of a good or 
service. In other words, the present invention provides a technology-enabled 
marketplace in which customers and merchants do business knowledgeably and 
efficiently. 

The intelligent multi-media market ("IMMM") of the present invention 
interconnects customers and merchants via a number of communications technologies, 
including the telephone, mail, fax transmission, email, and the Internet. This multi- 
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media aspect of the IMMM provides for the greatest possible accessibility and 
reachability for both customers and merchants. Customers and merchants are 
interconnected through server-based automated processes, centralized databases, and a 
number of transaction protocols. Processes within the IMMM, including software 
routines running on server-computers and procedures carried out through the 
occasional intervention by human technicians, construct and maintain an extensive 
database of customer and merchant information. Merchants are identified and 
included in the database via automated search engines, automated analysis, and 
technical analysis conducted by human technicians. Customers access the IMMM 
through one of the number of communications technologies in order to search for 
merchants offering a particular desired good or servicer The customers can. then 
submit requests for price quotes via the IMMM to the merchants identified in a search 
and subsequently receive quotes either from the IMMM or directly from merchants to 
which quote requests have been submitted. The IMMM furnishes requests for quotes 
to identified merchants by one of the number of communications technologies. 
Merchants can either accept the requests and respond to them, or opt out of the 
IMMM. The IMMM provides tools that allow customers to track submitted requests 
for quotes and that allow merchants to process requests for quotes. In addition* the, 
IMMM provides tools for conducting surveys of customers who have submitted 
requests for quotes with regard to the quality of service received from particular 
merchants. The IMMM provides customers with all the technological advantages of 
currently-available technology-enabled markets and, in addition, provides customers 
with a greater geographical breadth and thoroughness in searching for merchants, a 
greater ease of comparing prices offered by merchants, a greater ease in submitting 
requests for quotes, and tools for verifying a merchant's business practices and for 
tracking submitted requests for quotes. The IMMM provides merchants with all the 
technological advantages provided by currently-available technology-enabled markets 
and, in addition, provides merchants with greater geographical reachability for 
offering comparative prices in the marketplace, tools for processing requests for 
quotes, and automated feedback from customers. 
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Brief Description of the Drawing s 

Figure 1 illustrates the connectivity between the main components of the 
Intelligent Multi-Media Market. 

Figure 2 illustrates a representative transaction between a customer and 
the Intelligent Multi-Media Market. 

Figure 3 illustrates the basic transaction between the Intelligent Multi- 
Media Market and a merchant. 

Figure 4 illustrates the conceptual content of a merchant record within the 
Intelligent Multi-Media Market database. 

Figure 5 illustrates the requests for quotes tracking facilities provided by 
the Intelligent Multi-Media Market to both customers and merchants. 

Figure 6 represents a view of the contents of an example Intelligent 

.-'*■■■'.* 

'AMti-Media Market database pertaining to merchants wBb retail hew sport utility 
vehicles. 

Figure 7 represents the results of a first step in compiling a list of 
merchants to present to a customer. 

Figure 8 represents a map of the area in which an example customer 
lives and illustrates geographical filtering of an intermediate list of merchants. 

Figure 9 illustrates the process by which a customer submits a request for 

a price quote. 

Figure 10 is a flow-control diagram of the routine "connect to-IMMNfrand 

login." 

Figure 1 1 is a flow-control diagram of the routine "select category." 
Figure 12 is a flow-control diagram of the routine "input requirements." 
Figure 13 is a flow-control diagram of the routine "receive merchant list." 
Figure 14 is flow-control diagram that outlines Intelligent Multi-Media 
Market processing. 

Figure 15 is a flow-control diagram of the routine "process customer 

login." 

Figure 1 6 is a flow-control diagram of the routine "get category." 

Figure 17 is a flow-control diagram of the routine "get input 

requirements." 
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Figure 18 is a flow-control diagram for the routine "prepare merchant 

list" 

Figure 19 is a flow-control diagram for the routine "quote request 

submission." 

Figure 20 is a flow-control diagram for the routine "send out requests for 

quotes." 

Figure 21 is a flow-control diagram showing the merchant processing 
phase of the basic Intelligent Multi-Media Market transaction. 

Detailed Description of the Invention 

The present invention provides a new technology-enabled market, the 
intelligent multi-media market ("IMMM"). The IMMM thoroughly searches for and 
identifies merchants that provide a particular good or servic^fiesireJ^y a customer. 
The search can be tailored to produce a list of merchants that satisfy various 
constraints and customer preferences. The IMMM provides the list of identified 
merchants to the customer, and the customer can then submit a request for a price 
quote to one or more of the identified merchants through the IMMM. The IMMM 
then forwards the request for a price quote to those merchants identified by the 
customer as being merchants from whom the customer desires further information. 

The IMMM, on a continuous basis, compiles and maintains a detailed, 
cross-indexed database of merchants and categories of products and services. 
Merchants are automatically included in this database, but, upon receiving one or 
more requests for quotes from the IMMM, may elect to opt out either temporarily or 
permanently from the IMMM. The IMMM does not provide for exclusive 
agreements between the IMMM and merchants with regard either to inclusion of the 
merchants in the IMMM or with regard to submission of requests for quotes. 

The IMMM provides both customers and merchants with facilities for 
tracking submitted requests for quotes. Customers can follow a request for quotes 
through the IMMM and through processing of the request for quotes conducted by a 
merchant. The IMMM provides tools to facilitate processing of requests for quotes by 
merchants. The IMMM also provides for periodic and automatic surveys of 
customers with regard to their satisfaction with services provided by particular 
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merchants. Feedback based on these survey results are made available both to other 
customers and to the merchants surveyed. 

Customers and merchants can access the IMMM via telephone, mail, 
fax, email, the internet, and other advanced communications media. Thus, the 
intelligence aspect of the IMMM is provided by a centralized database, transaction 
protocols, and IMMM processes, both computational and human. The multi-media 
aspect of the IMMM relates to the rich variety of communications media through 
which the IMMM may be accessed both by customers and merchants. 

The IMMM will be described below irt four subsections. In the first 
subsection, an overview of the IMMM will be presented. In the second subsection, a 
database implementation is presented to facilitate discussion of the flow-control 
vdiagram illustration of IMMM transactions that followsjn the third subsection. The 
Mirth subsection wilf summarize the description of the IMMM and point out 
alternative embodiments and approaches. 

It should be noted, at the onset, that there are many different possible 
approaches through which the IMMM may be implemented. The database schema is 
provided in subsection 2 for illustrative purposes. Detailed implementations tailored 
to particular aspects of the IMMM are presented in additional, separately filed patent 
applications. The centralized database component of the IMMM can be implemented 
using any of the common types of database management systems, including network, 
hierarchical, relational, object-oriented, or hybrid database management systems. * 
Alternatively, an ad hoc database system may be implemented to serve as the database 
component of the IMMM. Many different computer languages can be employed in 
order to implement IMMM processes, and there are almost a limitless number of 
possible software implementations of the software components of the IMMM. 

Overview 

Figure 1 illustrates the connectivity between the main components of 
the IMMM. In Figure 1, a number of customers 102-106 are interconnected to a 
number of merchants 108-113. Customers and merchants may possess connections to 
different communications media for access to the IMMM. For example, 
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customer 102 is shown in Figure 1 as supporting fax exchanges 116, mail 
exchanges 118, internet access through a home PC 120, and telephone access 122. By 
contrast, customer 105 can access the MMM only via mail 124 or telephone 126. 
The IMMM is shown in Figure 1 as comprising a number of communications 
links 128, redundant fault-tolerant server computers 130 and 132, and a d%tabas|<^4. 
In a preferred embodiment, the database is mirrored on separate physical inedia'to 
prevent single points of failure. Data flows from customers 10^106 to the 
communications link 128, from the communications link to processors running on the 
server computers 130 artd 132^ and from the server computers 130 and 132 to the 
database 134. Data flows from the database 134 back to the customers 102-106 via 
server computers 130 and 132 and communications link 128. Data flows from -the 
database 134 through server computers 130 and 132 and communications link 128?1 
merchants ito-113 and, by opposite paths, from the merchants to the database 134 
Thus, the IMMM can be thought of as a logical crossbar interconnecting customers 
and merchants, with the logical crossbar selecting groups of merchants to which 
requests for quotes are broadcast from a customer depending on various customer 
preferences and criteria. 

Figure 2 illustrates a representative transaction between a customer anif 
the IMMM. Figure 2 is divided into two columns: (1) a column representing the 
customer 202; and (2) a column 204 representing the IMMM. Arrows, such as 
arrow 206, represent transfer of information from the customer to the IMMM, and 
arrows, such as arrow 208, represent transfer of information from the IMMM to the 
customer. Messages 210-217 represents information provided to the IMMM by the 
customer and information received by the customer from the IMMM. The messages 
are shown in Figure 2 as graphical, menu-like displays. When the customer is 
connected to the IMMM via the Internet, graphical messages are easily received and 
transmitted by the customer. On the other hand, when the customer is connected to 
the IMMM via only a telephone connection, information may be provided to the 
customer from the IMMM via audio menus and information provided by the customer 
to the IMMM via keypad-activated tones. The messages 210-217 in Figure 2 thus 
represent display and input of information appropriate to the type of communications 
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medium through which the customer is interconnected with the IMMM. These above- 
described conventions apply to Figure 3 as well, and in the interest of brevity will not 
be repeated below. 

After connecting and logging onto the internet, the customer is 
presented with a list of categories of products and services from which to select a 
particular category of product or service for which the customer wishes to submit a 
request for a price quote to one or more merchants. Message 210 displays a portion 
of a hierarchical list of categories of goods. In this case, and in the case of all other 
steps in Figures 2 and 3, presentation of information may require a single display, 
such as an internet-based graphical display, or may require a number of different 
steps, like, for example, selection of more and more specific categories presented, 
through audio selection lists over a telephone. The initial information transfer from 
the customer to the IMMM and vice versa is not shown in Figure 2. The Customer 
then selects the product category, in the case of Figure 2, a Brute sport utility vehicle, 
and transmits that selection to the IMMM. The IMMM then solicits additional 
information from the customer, in message 211, including selection of various options 
and preferences. Again, die options and preferences may be solicited in a large 
number of steps, depending on the number of options and preferences related to the 
selected category and depending on the communications medium through which die 
customer accesses the IMMM. Next, customer X selects options and preferences, in 
the case of Figure 2, a V8 engine, and returns the selections 212 to the IMMM. 
Based on the category, options, and preferences selected by the customer, the IMMM 
prepares an initial list of merchants offering the selected product or services and 
meeting the criteria represented by the options and preferences selections 213 made by 
the customer and the IMMM then presents the initial list of merchants to the customer. 
The customer may then select a subset of the identified merchants, represented in 
Figure 2 by the selection of "Smallville Motors" and "SUV Mart" 214, and may then 
return the edited list of merchants to the IMMM. 

Finally, the IMMM submits to the selected merchants requests for 
price quotes that include certain of the options and preferences selected by the 
customer for the indicated category of product or services. Sometime later, the 
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customer receives completed price quotes back from the merchants, represented in 
Figure 2 by messages 215 and 216. The merchants can send the quotes directly to the 
customer via a communications medium preferred by the customer, or, alternatively, 
can return the quotes to the IMMM for forwarding to customers. The customer may 
then choose to accept one of the price quotes, represented in Figure 2 by message 217, 
and direct the acceptance to a merchant either directly, or via the IMMM. Figure 2 
thus represents the basic market transaction supported by the IMMM. The IMMM 
also supports additional types of customer transactions, not shown in Figure 2, 
including transactions that allow a customer to modify the customer's user profile. 

Figure 3 illustrates the basic transaction between the IMMM and a 
merchant. First, the merchant receives one or more requests for price quotes from the 
IMMM, represented in Figure 3 by messages 302 and 304. If the 'merohant has not 
previously received requests for quotes from the IMMM, the IMMM^fers the 
request for quotes to the merchant via a communications medium identified by the 
IMMM from any of a number of sources of information, including the telephone 
yellow pages, advertising, internet websites, catalogs, and other types of information. 
The contact information for the various identified communications media through 
which a merchant can receive requests for quotes are stored in the IMMM database 
(134 in Figure 1). After receiving the requests for quotes, the merchant has a number 
of options. The merchant can opt out of the IMMM, either temporarily or 
permanently, as represented in Figure 3 by message 306. The requests for quotes 
contain sufficient information to allow the merchant to reply to the IMMM, such as 
internet hyperlinks, return email addresses, phone numbers, etc. Alternatively, the 
merchant can send price quotes back to either the IMMM or directly to customers via 
contact information contained in the request for quotes 302 and 304. Quotes are 
represented in Figure 3 by messages 308 and 310. A merchant may conduct a variety 
of other transactions with the IMMM, including furnishing additional merchant 
information. These additional transactions are not shown in Figure 3. 

Figure 4 illustrates the conceptual content of a merchant record within 
the IMMM database (134 in Figure 1). It should be noted that the contents of a 
merchant record may be distributed throughout a . number of different database 
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records, entries, or objects. The logical merchant record, shown in Figure 4, 
illustrates the type of information that can be extracted from the database with regard 
to a particular merchant. The merchant record 402 may contain the name of the 
merchant 404 and a unique ID 406 that numerically represents and identifies the 
merchant. The logical merchant record may contain one or more physical addresses 
representing the merchant's retail locations 408 along with contact information for the 
various retail locations 410. In addition, the logical merchant record may contain an 
ordered list of preferred communications media and media addresses for receiving 
requests for quotes 412. The logical merchant record may contain extensive lists of 
product and service categories offered for sale by the merchant 414. The logical 
merchant record may, in addition, contain results of surveys conducted by the IMMM 
to evaluate the merchant's performance 416.. Many other additional typ^ of 
information may be contained within the logical merchant record 418-4^0. ^ 
merchant record thus provides the basis for constructing lists of merchants to furnish 
to IMMM customers in response to selection by customers of categories of products 
and services, preferences, and options. The IMMM database (134 in Figure 1) also 
includes logical category records, logical customer records, and logical requests for 
quote records. Again, as with the merchant records, these logical records may be 
distributed over a number of different database tables, records, entries, or objects. 

The IMMM, in addition to the basic request for quotes submission and 
quote furnishing transactions illustrated in Figures 2 and 3, provides a number of 
advanced information tools to both customers and merchants. Figure 5 conceptually 
illustrates the requests for quotes tracking facilities provided by the IMMM to both 
customers and merchants. This facility provides views of outstanding requests for 
quotes to merchants and to customers. In Figure 5, these views are displayed as 
graphical displays 502 and 504 obtained from the IMMM via 'the Internet on a 
merchant computer 506 and a customer computer 508, respectively. The requests for 
quotes, represented in Figure 5 by small squares, such as square 510, can be thought 
of as inhabiting a three-dimensional Cartesian volume within the IMMM database. A 
view of a portion of that Cartesian volume appears within the three-dimensional 
coordinate system comprising the following three orthogonal axes in Figure 5: (1) the 
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customer axis 512; (2) the merchant axis 514; and (3) the requests for quotes axis 516. 
Thus, the columns of stacked requests for quotes 518-520 each represents the total 
outstanding requests for quotes from one customer to one particular merchant. 
Because only a small window into the Cartesian volume of requests for quotes is 
shown in Figures, the first column 518 is arbitrarily assigned to customer m, the 
second column 519 is assigned to customer m+1, and the third^lumn is assigned to 
customer m+2. Similarly, each of the three rows of stacked requests for quotes 522- 
524 represents all the outstanding requests for quotes submitted to a particular 
merchant. The first row 522 is arbitrarily assigned to merchant n 9 the second row 523 
is therefore assigned to merchant w+ 7, and the third row 524 is assigned to merchant 
n+2. The assignments of customers and merchants presumes a right-handed 
Cartesian coordinate system with indices increasing to the right and downward alqjj^ 
the customer axis* 5 12 and the merchant axis 514, respectively, the final axis SfS?: 
represents an ordered sequence of requests for quotes submitted by a particular 
customer to a particular merchant. Thus, for example, the requests for quotes 526 
529 were submitted to merchant n by customer m. 

The Cartesian volume representation of the outstanding requests for 
quotes is simply one logical way to view all the outstanding requests for quotes 
contained within the IMMM database (134 in Figure 1). This conceptual view of the 
outstanding requests for quotes facilitates an understanding of the requests for quotes 
that are accessible to the merchant and to the customer. For example, merchant n+2 
can view all the outstanding requests for quotes located in row 524. The MMM 
viewing tool will provide navigational buttons or other types of navigation devices to 
allow merchant n+2 to traverse row 524 to select successive stacks of requests for 
quotes representing the requests for quotes submitted to merchant n+2 by particular 
customers. These navigational devices then allow merchant n+2 to select any one of 
the outstanding requests for quotes on the merchant's PC 506. In similar fashion, 
customer m+2 may display any of the outstanding requests for quotes within 
column 520 that represent all the requests for quotes submitted by customer m+2 to 
any of the merchants. It should be noted that additional types of views of the requests 
for quotes are also available to customers and merchants. For example, multiple 
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requests for quotes for a particular good or service from a customer to multiple 
merchants may be submitted in one operation by the customer, and may be aggregated 
together within a multiple-merchant record for display to a customer. 

Although a three-dimensional volume is shown in Figure 5, the 
outstanding requests for quotes can logically be considered to reside in a more 
complex hyper-volume with additional dimensions representing the path, or trajectory, 
of a given request for quotes through the IMMM and through processing following 
submission to a merchant. Also, various IMMM tools can extract summary 
information from all of the outstanding requests for quotes accessible by a merchant or 
customer, and the IMMM can search through the accessible outstanding requests for 
quotes in order to final and present subsets of the accessible outstaiidifig^ requests for" 
quotes based on various criteria. Thus, the centralized IMMM datahase (134 in 
Figure 1) provides information storage that enables the IMMM to provide 
sophisticated requests for quotes tracking tools to both merchants and customers. 

Figures 6-8 illustrate the process by which the IMMM selects a list of 
merchants to present to a customer for submissions of requests for quotes for a 
particular good or service. Figure 6 represents a view of the contents of the IMMM 
database pertaining to merchants retailing new sport utility vehicles. In a relational 
database implementation of the IMMM database, this table might represent a view or 
temporary, table constructed from the contents of the many different database tables 
that together comprise collections of logical merchant records, such as the logical 
merchant records shown in Figure 4. Generally, an implementation will contain many 
additional columns and rows representing different characteristics of the merchants 
and a great deal more merchants, respectively. 

Figure 7 represents the results of a first step in compiling a list of 
merchants to present to the customer. Continuing with the example of Figure 2, the 
customer is seeking quotes on new Brute sport utility vehicles. Thus, the IMMM has 
filtered the information illustrated in Figure 6 into a smaller list, shown in Figure 7, 
that includes only those merchants that retail new Brute sport utility vehicles. 
Generally, for each category of product or service, the IMMM will determine the 
maximum number of merchants to present to the customer and will continue to filter 
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the initial list with regard to customer preferences and selected options until a list 
smaller than the maximum list size has been determined. The final criteria employed 
by the IMMM, for retail sales of products such as automobiles, is to filter the list of 
merchants with regard to geographical proximity of the merchants to the customer. 
One approach to filtering the intermediate lists of merchants by geographical 
proximity is illustrated in Figure 8. Figure 8 represents a map of the area in which the 
customer lives. The IMMM filters the intermediate list by logically considering 
merchants within circles of increasing radius until an adequate number of merchants 
can be filtered from the intermediate list of merchants. For example, in Figure 8, the 
IMMM starts with a circle of radius 1 mile §02 centered about the location of the 
customers residence 804. By applying a distance function to the addresses of 
customer and each merchant in the intermediate list of merchants, respectively, the 
IMMM can determine that only one merchant, "Smallville Motors" 806, is located 
within one mile of the customer's residence. The IMMM then increases the radius of 
the circle to two miles 808 which further includes "Trust Me Auto" 810. If, in this 
example, the IMMM is seeking at least three merchants to which the customer can 
submit quotes, the IMMM further increases the radius of the circle to three miles 812 
and discovers, through application of the distance function, that a third merchant 
"SUV Mart" 814 can now be included in the list. Thus, following geographical 
filtering, the IMMM has selected a list of three merchants that offer the particular 
sport utility vehicle desired by the customer, that meet the preferences and options 
selected by the customer, and that are geographically located closest to the customer. 

For goods and . services more easily offered from a distance, the 
IMMM may choose different radii for geographical filtering, or may not employ 
geographical filtering. The IMMM may employ vasdy different preferences and 
options for different categories of products and services. Thus, the IMMM employs 
the information contained in the IMMM database to best advantage to select lists of 
merchants for each different category of products and services to present to individual 
customers. 
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Example Database Schema 

In this subsection, a generalized implementation of the IMMM database 
is presented. This generalized database schema provides a basis for implementing the 
MMM transactions outlined in the previous subsection as well as a basis for IMMM 
automated survey techniques. In addition, the database schema presented in this 
subsection is sufficiently extensible to allow for the ongoing database construction and 
maintenance by which the IMMM continuously enhances the search capabilities that 
the IMMM offers to customers. 

The database schema presented in this subsection is based on the 
relational database model. Seventeen relational database tables are described-, below, 
in table form as well as in SQL-like table creation commands. Each table contains a 
few sample rows in order to illustrate the nature of the data contained in the tables as. 
well as the interdependences between tables. A live, functioning database contains far 
more information, with some tables containing hundreds of thousands to millions of 
rows. The generalized database schema presented in this subsection wilt facilitate 
discussion of flow-control illustrations of the IMMM transaction model and protocol 
presented in the following subsection. 



WO 00/42547 



22 



PCT/USOO/01210 



Tables 5-8 store basic merchant information. Tables 5-8 are presented 

below: 

Table 5 \ . ^ V - 

merchants 



fieldname 


num 


type 


name 


1 


2 


street 
address 


2 


2 


post 
address 


3 


2 


email 
address 


.4 •-■ 


- .) 2 


fax number 


6 


1 


phone 
number 


5 


1 



CREATE TABLE merchants 
( field_name VARCHAR(128), 
num INTEGER, 
type INTEGER) 



Table 6 
merchant varchars 



m id 


num 


value 


369 


1 


Bob's Used Cars 


369 


2 


361 Main St, 




Bellevillle.MN 50120 


369 


3 


P.O. Box 897 




BluntsviUe, MN 50122 


369 


4 


Bobs@bob.com 


8896 


1 


Tim's Stereos 


8896 


2 


3106 5 th Avenue 




New York, NY 10002 



CREATE TABLE merchant varchars 
( mid INTEGER, 

num INTEGER, 

value VARCHAR(128)) 
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Table 7 
merchant ints 



mid 


num 


value 


369 


5 


825 113 1962 


369 


6 


825 114 1401 


8896 


5 


202 101 7777 


8896 


6 


202 139 8121 


37 


5 


888 962 1111 


37 


6 


814 999 7777 



CREATE TABLE merchantints 
• • . ... •• . ; (mjd INTEGER, ,, 

num INTEGERv 
value INTEGER) 



Table 8 
merchant contact 



m id 


cd id 


primary 


secondary 


369 


4 


1 


2 


369 


82 


3 


1 


369 


6 


3 


3 


127777 


112 


3 


3 


127777 


113 


3 


3 


127777 


114 


3 


3 


8896 


96 


3 


3 



CREATE TABLE merchant_contact 
(mid INTEGER, 

cid INTEGER, 

primry INTEGER, 

secondary INTEGER) 



Table 5 describes the different types of basic merchant information contained in 
Tables 6 and 7. Table 5 contains the following three columns: (1) field name, a text 
description of a type of information, or information field, contained in either Table 6 
or Table 7; (2) num, an integer identifier for a particular type of information, or field; 
and (3) type, an integer indicating the data type of the data field. In the generalized 
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database schema presented in this subsection, two data types are used, integer data 

having a type of "1," and variable length character data, or strings, having a type 

designation of "2. w Table 6 contains all the fields having fields of type 2, or, in other 

words, fields having a type of variable length character string. Table 7 contains those 

fields having type 1, or, in other words, having a data type of integer. Note that, in 

this example, we assume that the SQL-like data type INTEER is large enough (by bits) 

to hold phone numbers. For SQL-like implementations having 32-bit integers, a 

different SQL-like data type can be used for phone numbers, such as the data type 

"NUMERIC(16,0). W More elaborate, and more capable database implementations 

may contain additional data types for merchant information fields, and additional 

tables 16 contain values of those additional data types. For example, when the IMMM 

provides facilities for automated electronics funds transfer, a special field. type -for 

security-protected, verifiable, and^lasily invoked account numbers may be employed 

# 

As another example, date or time of day data types may find common usage in 
descriptive fields related to merchants. 

Tables 6 and 7 contain the basic merchant information. When a new 
merchant is identified by the IMMM, the new merchant is assigned a unique merchant 
ID. As with all other ID's used in this generalized database schema, the IMMM must 
have a method for allocating unique ID's in a reusable fashion, or, at least, must use 
large enough integers to represent ID's so that monotonically increasing ID values can 
be used without danger of rollover. Once a unique merchant ID has been assigned to 
the new merchant, values for the fields described in Table 5 are entered for that 
merchant into Tables 6 and 7. When information for certain of the fields cannot be 
gleaned from the sources used by the IMMM to identify new merchants, the value 
NULL may be used to indicate lack of information. Alternatively, the row 
describingthat field can simply be left out of Table 6 or Table 7. Both Tables 6 and 7 
have the following three columns: (1) mjd, the unique merchant ID identifying a 
particular merchant; (2) num, the identifier of the particular field as shown in the 
second column of Table 5, discussed above; and (3) value, the value of the field 
identified by the field identifier in the preceding column. In the case of Table 6, the 
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value is a variable length string value, and in the case of Table 7, the value is an 
integer. 

If the contents of Table 5 are thought of as defining a simple merchant 
record, analogous to the logical merchant record described in Figure 4, above, then an 
instantiation of a particular merchant record can be constructed from the values 
contained in Tables 6 and 7. For example, referring to the sample data contained in 
Tables 5-7, above, the following logical merchant record is easily constructed: 

merchant id: 369 
name: Bob's Used Cars 

street address: 361 Main Street, Belville, MN, 50120 > • 
host address: P.O. Box 897, Glensville, MN 50122 
' .^ait^dress: Bob 1 s@bob.com , 

fax number: (825) 113-1962 
phone number: (825) 114-1401 

Table 8 contains a preferred contact method for submitting requests for 
quotes to merchants. This table contains the following four columns: (1) m id, the 
merchant identifier identifying a particular merchant; (2) cid, a unique identifier of a 
category of product or services, to be discussed below, provided by the merchant 
identified by the merchant ID in the first column; (3) primry, an integer identifier of a 
contact method or communications media preferred by the merchant for submission of 
a requests for quotes of a category identified by the identifier in the preceding column; 
and (4) secondary, a second preferred communications media for receiving 
submissions of requests for quotes. The integer values indicate different types of 
contact methods. For example, the value "1" may indicate mail, the value "2" may 
indicate telephone, and the value "3" may indicate Internet-based submissions ^ia 
IMMM web-based facilities provided to customers. Various other types of 
communications media through which merchants may receive quotes from the IMRIM 
will be designated with additional integer values. 

Tables 9-12, shown below, store basic information related to 
customers. These tables are analogous to Tables 5-8. described above. The logical 
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customer record is defined by the contents of Table 9, and values for fields of logical 
customer records are stored in Tables 10 and 11. Preferred methods for customer 
reception of completed price quotes from merchants are stored in Table 12, 
analogously to storage of merchant contact information in Table 8. 

Table 9 
customers 



field name 


num 


type 


name 


1 


2 


street address 


2 


2 


post address 


3 


2 


. email address 


4 


2 


phone number 


5 - 


1 - " / 


fax number 


6 


1 • 



CREATE TABLE customers 
( field_name VARCHAR(128), 
num INTEGER, 
type INTEGER) 



Table 10 
customer_varchers 



est id 


num 


value 


-2000 


1 


John Everett 


2000 


2 


3612 Blackhawk Dr. 
Orlando, CA 94101 


2000 


3 


3612 Blackhawk Dr. 
Orlando, CA 94101 


2000 


4 


ieu(5).woes.edu 


2001 


1 


Billy Joe Wells 


2001 


2 


317 Pines Street 
Bestville, GA 39176 



CREATE TABLE customer_varchars 

( cstid INTEGER, 
num INTEGER, 
value VARCHAR(128)) 
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Table 11 
customer ints 



est id 


num 


value. 


2000 


5 


510 462 8887 


2000 


6 


510 462 ^73 


2001 


5 


312 8731112 


2001 


6 


312 873 1112 


2002 


5 


849 761 8600 


2002 


6 


849 761 8600 



CREATE TABLE customer_ints 

(cstjd Integer, 

num INTEGER, 
Value INTEGER) 



Table 12 
customer contact 



est id 


c id 


primry 


secondary 


2000 


4 


I 


2 


2000 


82 


1 


2 


2000 


462 


3 


3 


96 


123 


3 


3 


96 


-9 


3 


. 3 , 


96 


842 


3 


3 


96 


11 


3 


3 



CREATE TABLE customercontact 
( cstjd INTEGER, 

cid INTEGER, 

primry INTEGER, 

secondary INTEGER) 

Table 13, shown below, contains a hierarchically-organized list of 
product and service categories. Table 13 contains the following columns: (1) pejd, an 
integer identifier that identifies the parent category of a particular category, where top- 
level categories having no parents have a value of zero in the pc_id field; (2) category, a 



WO 00/42547 28 PCT7US00/01210 

variable length character string that describes the product or service; and (3) c_id, an 
integer that uniquely identified the product or service represented by the category. 

Table 13 
categories 



pcid 


category 


cid 


0 


automobiles 


2 


2 


new 


4 


2 


used 


82 


0 


stereos 


67 


67 


amplifiers 


841 


841 


new 


1117 


841 


used 


1118 


67 


tuners 


906 


906 


new 


3002 



CREATE TABLE categories 
( pcjd INTEGER, 
category VARCHAR(128), 
cjd INTEGER) 



Referring to the sample data stored in Table 13, there are two top-level product 
categories: "automobiles," having c id = 2, and "stereos", having cjd = 67. The 
category "automobiles" has subcategories "new" and "used," and the category 
"stereos" has subcategories "amplifiers" and "tuners." The "amplifiers" subcategory 
itself has two subcategories, "new" and "used," and the subcategory "tuners" has 
subcategory "new." In a live IMMM database, there are likely to be thousands or 
hundreds of thousands of categories and subcategories. In addition, rather than a 
single hierarchical ordering, other types of organizations of categories and products 
may be employed. 

Table 14, shown below, contains information related to specific 
categories for each merchant that offers a product or service of that category. This 
information can be extracted by the IMMM and used during the searching and filtering 
operations that the IMMM employs to provide a list of merchants to customers 
seeking a particular good or service. Table 14 contains the following columns: (1) 
mjd, a unique identifier of a particular merchant; (2) c id, a unique identifier of a 
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particular category of a product or service; (3) name, a variable length character string 
text description of the piece of information; (4) num, an indication of the order in 
which the information might be displayed in a graphical display of information related 
to the particular merchant and category; and (5) value, a variable length character 
string representing a value associated with a particular merchant and category. 



Table 14 
merchantcategoryinfo 



m id 


cid 


name 


num 


value 




369 


4 


brand 


i • 


Fordge 




369 


4 


brand 


2 


Cheville 




369 


4 


brand 


3 


Beaver 




369 


82 


brand 


1 


Beaver 




369 


82 


brand 


2 


Fordge 





CREATE TABLE merchant category info 
( m_id INTEGER, 

c_id INTEGER, 

name VARCHAR(128), 

num INTEGER, 

value VARCHAR(128)) 



In the example data shown above in Table 14, various brand names associated with 
new and used automobiles, identified by category identifiers "4" and "82," 
respectively can be seen in to be associated with "Bob's Used Cars." Thus, it can be 
seen from the contents displayed for Table 14 that Bob's Used Cars offers new 
Fordge, Cheville and Beaver automobiles and used Beaver and Fordge automobiles. 
In a live, functioning IMMM database, Table 14 might include hundreds of thousands 
or millions of individual pieces of information related to particular merchants and 
categories. In addition, Table 14 may be combined with auxiliary tables in order to 
support different types of values, such as integer values, real number values, dates, 
times, graphical objects, and other such types of values that might be used for 
displaying information about a merchant's offerings. 
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Tables 15-17, shown below, together contain information related to 
particular preferences stored for particular clients related to particular categories. The 
methodology for storing these preferences is quite similar to the methodology for 
storing base information about merchants in Tables 5-7, and custqme^in Tables 9-1 1 , 
above. The only substantive difference is that preferences are identified by a 
combination of two identifiers, or keys, namely a preference ID stored in coluitui 
"p_id" and a category ID, stored in column "cid" in Table 15. The preference ID 
uniquely identifies a particular preference associated with a particular category. 

Table 15 
preferences 



pid 


cid 


name 


num 


type 


997 


4 


brand 


1 


2 


998 


4 


transmission 


2 ' 


r 


12003 


82 


brand 


1 


■ 2 


12007 


82 


age 


2 


1 


847 


67 


brand 


1 


2 



CREATE TABLE preferences 
(pid INTEGER, 

cid INTEGER, 

name VARCHAR(128), 

num INTEGER, 

type INTEGER) 
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Table 16 
preference jvarchars 



est id 


pid 


value 


2000 


997 


Fordge 


2000 


998 


Automatic 


2000 


12003 


Beaver 


8000 


997 


Cheville 


2000 


847 


Yamaguchii 


2001 


997 


Bear 



CREATE TABJJi preference^varchars 
(cst_id INTEGER,; 
p_id INTEGER, 
' value VARCHAR(128)) ; ^ 



Table 17 
preferenceints 



est id 


pid 


value 


2000 


12007 


6 


8000 


12007 


3 


9176 


12007 


1 


2001 


12007 


8 


36 


12007 


7 


12 


12007 


1 



CREATE TABLE preference ints 
(cstjd INTEGER, 
pjd INTEGER, 
value INTEGER) 



Because the methodology employed to store preferences is so similar to the above- 
described methodologies for storing base information about clients and merchants, the 
columns in Tables 15-17 will not be described in detail. Instead, the information 
storage strategy is easily seen in the example data shown above in Tables 15-17. For 
example, Table 15 contains two different types of preferences associated with the 
category "new automobiles." These two preferences have preference identifiers of 
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"997" and "998." In a graphical display listing for soliciting preferences, the value 
stored in the column "number" indicates the order of listing or displaying the 
preferences. The text description of one preference is "brand" with a data type of 
variable length character string, and the text description of the second preference 
associated with new automobile is "transmission," also having a data type of variable 
length character string. Referring now to Table 16, one can see that the customer 
identified by the cstjd "2000 n prefers the brand "Fordge" with respect co new 
automobiles. Similarly, the customer identified by the cst id "2000" has a preference 
for automatic transmissions with regard to new automobiles. Referring back to 
Table 10, the customer with cst_id "2000" is named "John Everett. " 

.'■ Table 18 contains descriptions of forms related to specific categories of 
products and services for submission of requests for quotes. Multiple forms for any - 
particular category can be accommodated by Table 18 since each form is uniquely 
identified by a form ID. 



Table 18 
formsdescriptions 



fid 


cid 


query 


num 


type 


field_id 


table 


831 


82 


customer name 


1 


2 


1 


customer_varchars 


831 


82 


customer address 


2 


2 


2 


customer_varchars 


831 


82 


desired brand 


3 


2 


12003 


preference_varchars 


831 


82 


desired 
maximum age 


4 


1 


12007 


~ preferenceints 


831 


82 


customer phone 


5 


1 


5 


customervarchars 


77 


4 


customer name 


1 


2 


1 


customervarchars 


77 


4 


customer address 


2 


2 


2 


customervarchars 



CREATE TABLE forms descriptions 

(f_id INTEGER, 

sc_id INTEGER, 

query VARCHAR(128), 

num INTEGER, 

type INTEGER, 

fieldjd INTEGER, 

table VARCHAR(128)) 
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Table 18 contains the following columns: (1) f id, a unique identifier identifying a 
particular form; (2) cjd, a unique identifier identifying a particular category of 
product or service; (3) query, a variable length character string text description of a 
particular item of information; (4) num, an indication of the ordering of information 
requests within a particular form; (5J type, an indication of the data type of the 
expected response; (6) fieldid, a unique identifier for a data-containing field in 
Tables 10, 11, 16, or 17; and (7) table, the name of one of Tables 10, 11, 16, or 17 
that contains the data representing a response to the query represented by a row in 
Table 18. As with logical merchant records, and logical customer records, the 
IMMM can extract a logical form for a request for quotes form the information 
contained in Table i8. For example, the following logical form identified by the form ■ 
identifier "831," related to a request for a price quote on a used automobile, can fee 
•extracted from the sample data included in Table 18 above: 

customer name: 

customer address: 

desired brand: 

desired maximum age: 

customer phone: 

Table 19, shown below, contains information regarding the forms used 
by merchants for different categories of products and services. . > W- 
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Table 19 

merchant form list 



m id 


f id 


c id 


369 


831 


82 


369 


839 


97 


369 


77 


4 


369 


1007 


993 


8896 


831 


82 


8896 


839 


97 


8896 


77 


4 ' 



CREATE TABLE merchant Jormjist 
(mid INTEGER, - 

f_id INTEGER, 
c_id INTEGER) 



Table 19 contains the following columns: (1) m id, a unique identifier for a particular 
merchant; (2) f id, a unique identifier for a particular form; and (3) cid, a unique 
identifier for a particular category of product or service. Thus, for example, the first 
row in Table 19, above, indicates that the merchant having merchant ID "369," i.e: 
"Bob's Used Cars, " uses the form identified by form ID "831," described above in the 
description of Table 18, for receiving requests for quotes on used cars. 
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quotes. 



Table 20, shown below, represents a list of outstanding requests for 

Table 20 

requests_f brjjuote 



q_id 


cst_id 


f_id 


mid 


time_received 


time submitted 


96 
97 


2000 


831 


492 


Dec. 13, 1998 11 


:i0PM 


NULL 


2000 


831 


369 


Dec. 13, 1998 11 


:10PM 


NULL 


98 


2001 


77 


369 


Dec. 13, 1998 11 


11PM 


NULL 


99 


17 


9128 


8896 


Dec. 13, 1998 11 


12PM 


NULL 


100 


162 


179 


781 


Dec. 13, 1998 11 


12PM 


NULL 


101 


800001 


53 


662 


Dec. 13, 1998 11 


13PM 


NULL 



CREATE TABLE requests_for_quote 



(q_id 
cstid 
f_id 
mid 

time_received 
last submitted 



INTEGER 

INTEGER, 

INTEGER, 

INTEGER, 

DATET1ME, 

DATEITME) 



Table 20 has the following six columns: (1) q_id, a unique identifier identifying the 
request for quote; (2) cstjd, a unique identifier identifying a particular customer; (3) 
fjd, a unique identifer identifying a particular form; (4) m id, a unique identifier 
identifying a particular merchant; (5) timejreceived, the date and time that the request 
for quotes was submitted to the IMMM by the customer identified by the customer ID 
in a previous column; and (6) lastsubmitted, the date and time that the request for 
quotes was last submitted to the merchant identified by the merchant ID in the 
previous column. Note that the values that represent responses to informational 
requests in a form are contained in Tables 10, 11, 16, and 17. Thus, the IMMM is 
able to use the information contained in each row of Table 20 to construct a logical 
request for quotes form and response to the queries within the form. For example,»the 
first row in Table 20, shown above, indicates that a request for quote, identified by the 
request for quotes ID "97," was submitted by customer "John Everett" to "Bob's Used 
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Cars" for a used automobile on December 13, 1998 at 11:10PM. The IMMM has not 
yet submitted the request for quotes to the merchant, indicated by the value NULL in 
the last field of the row. The IMMM, using information contained in Tables 8, 10, 
11, 16, and 17, can extract the following completed request for quotes form that 
corresponds to the entry in the first row of Table 20, above: 

customer name: John Everett • 

customer address: 3612 Blackhawk Drive, Orlando, CA 94101 

desired brand: Beaver 

desired maximum age: 6 

customer phone: (510) 462-8887 
Finally, Table 21, shown below, contains information collected, by 
automated survey mechanisms within the IM^M. 

Table 21 

surveys 



q_id 


quality 


timeliness 


value 


service 


comments 


97 


1 


2 


2 


5 


service was really bad 


98 


2 


2 


2 


2 




99 


3 


3 


3 


3 


never again 


100 


1 


T 


1 


1 


great deal at a great price . 



CREATE TABLE SURVEYS 



(qjd 
quality 
timeliness 
value 
service 
comments 



INTEGER, 

CHAR, 

CHAR, 

CHAR, 

CHAR, 

TEXT) 



Table 21 contains the following columns: (1) q_id, a unique identifier identifying a 
particular submitted request for quote; (2) quality, a value for the overall quality of the 
service obtained by the customer with relation to the submitted quote; (3) timeliness* a 
rating of the timeliness of fulfilling the request for quote; (4) value, the customer's 
estimation of the value provided by the merchant with respect to the particular request 
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for quote; (5) service, the customer's estimation of the quality of service provided by the 
merchant; and (6) comments, a text field in which a customer's comments can be 
entered. Many additional types of comments representing different evaluation 
characteristics may be included in Table 21 . Note that all the information about the 
customer, the merchant, and the nature of the submitted request for quotes can be 
obtained by using the q_jd value in the first column of Table 21 to find an entry in 
Table 20, described above, from which an entire logical request for quotes can be 
extracted. 

Again, a live and functioning IMMM database includes many additional 
columns, additional tables, or different tables and columns from those described above. 
Form information stored in the IMMM database reflects the diffeifent types of 
capabilities and services that the IMMM can provide to both customers and merchants? : 
The database schema described in this subsection is adequate to support the basic 
IMMM transactions and protocols described in overview in the preceding subsection 
and described in detail in the following subsection. 

Description of the Basic IMMM Transaction and Protocols 
In this subsection, flow-control diagrams are presented to describe, in 
detail, the basic IMMM transaction model and the IMMM processers which facilitate 
and support the transaction model. There are three main phases of the basic IMMM 
transaction. The first phase relates to a custpmer^ jequest for quotes submission,- 
described in Figures 9-14. The second phase is IMMM processing of a customer's 
request for quotes, described in Figures 15-20. The final phase relates to processing 
of requests for quotes by a merchant, described in Figure 21. These phases, 
particularly the first two phases, may be interwoven in time. 

Figure 9 illustrates the process by which a customer submits a request 
for a price quote. In step 902, the customer connects to, and logs into, the IMMM by 
calling the "comment to IMMM and login routine," to be described below. In step 904, 
the customer selects a category of goods or services for which the customer desires to 
submit a request for quotes via a dialog with the IMMM, encapsulated in the "select 
category" routine to be described below. If the customer is successful in selecting a 
category, as detected in step 906, the customer proceeds to step 908 in which the routine 
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"input requirements" is called to conduct a dialog with the IMMM in order to furnish 
additional information about the product or service desired by the customer, customer 
preferences, and various types of options available to the customer for the selected 
category. If requirements are successfully selected, as detected in step 910, the 
customer proceeds to step 912, where the customer selects a preferred contact method. 
Because the routine "input contact method" is straightforward, it will not be discussed 
below. In the routine "input contact method," the IMMM queries the customer for a 
primary and secondary contact method for receiving quotes for goods or services 
represented by the selected category, and places the information into the IMMM 
database. Using Table 12, described above, as an example, the IMMM may execute the 
following SQL-like command to determine whether the customer has previously entered 
contact information for the selected category: 

SELECT primry r secondary FROM customer_contact 
WHERE cstjd = 2000 AND cjd = 82 
Note that the above example SQL-like command assumes the unique identifier 
identifying the customer to have a value "2000" and that the selected category has the 
categoiy identifier "82." Using the example data from the preceding subsection, this 
would correspond to checking whether customer "John Everett" has previously 
identified a preferred contact method for receiving price quotes on used automobiles. In 
the case that no. previous contact information was entered into Table 12, the IMMM can 
add that information to Table 12 using a SQL-like command such as the command that 
follows: 

INSERT INTO customer_contact VALUES (2000, 82, 1,2) 
If, on the other hand, Table 12 already contains contact information for a selected 
category of product or service, the IMMM can compare the information returned from 
the above SELECT statement to the information furnished by the customer in response 
to the solicitation of contact information from the customer by the IMMM to decide 
whether the information stored in the IMMM in step 912 database needs to be updated. 
If the information needs to be updated, the IMMM may update the stored information 
by the following SQL-like command: 

UPDATE customer_contact 
SET primry = 1 , secondary = 2 
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WHERE cstjd = 2000 AND cjd = 82 
These basic SQL-like commands can be used to extract information from the IMMM 
database, insert information into the IMMM database, and update information already 
stored in the IMMM database in all the transactions, transaction protocols, and routines 
to be discussed in this subsection. Thus, the detailed SQL-like commands will not be 
provided for the information obtaining and information storing stops in the transaction 
protocols, transaction models, and routines to be discussed below. 

It should be noted that most of the steps in the flow-control diagrams described 
in this subsection will be represented as routine calls. This is because the details within 
the steps will vary depending on the type of communications medium to which the 
customer or merchant is connected to the IMMM. In the case of the connection through 
a web page, for example, an entire set of preferences, options, customer information, or 
other types of information can be obtained in a single step based on custom^ toput to 
check boxes, active text fields, or other selection objects imbedded in a displayed web 
page. On the other hand, a series of tedious audio menu steps may be required to solicit 
and input the same information in the case that the customer or merchant is connected to 
the IMMM only by telephone. 

Once the customer has input the contact information, the customer 
receives, in step 914, list of merchants identified by the IMMM by conducting searching 
and filtering operations on merchant data stored in the IMMM database in the routine 
"receive merchant list," discussed below. If the customer chooses to submit a request 
" for quotes to merchants from the merchant list, as determined in step 916, the customer 
indicates to the IMMM the customers desire to submit requests for quotes to merchants 
in the final list in step 918. If the customer desires to submit requests for quotes for 
additional categories, as detected in step 920, control flows back to step 904. Otherwise, 
the submission of a request for quotes transaction is completed. In the case that 
selection of a category or input of requirements fails, as detected in steps 906 and 910, 
respectively, the customer may elect to attempt to select a different category of product 
or service in step 922. 

Figure 10 is a flow-control diagram of the routine "connect to IMMM 
and login." In step 1002, the customer connects to the IMMM through a selected 
communications medium. This may require the customer to dial a telephone number 
supported by the IMMM, send an email message to the IMMM at the IMMM's email 
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address, or open an IMMM web page via an Internet browser. In the following 
discussions, it will be assumed that customers and merchants will be connected to the 
IMMM through a selected communications medium and that the various information 
solicitations and transfers in the steps of the flow-control diagrams will be appropriately 
tailored to the selected communications medium. 

In step 1004, the customer receives a login prompt from the IMMM. In 
the login prompt, the IMMM needs to request a sufficient amounf of information to 
retrieve the customer identifier corresponding to the customer from the IMMM 
database, and to identify and verify that the customer claiming the identified customer's 
identity is, in fact, that customer. If the customer is a new customer, as detected in 
step 1006, the new customer receives a new customer information solicitation prompt 
from the IMMM in step 1 008 and responds to that prompt in step 1010. In the case of 
certain types of communications medium, steps 1008 and 1010 may be repeated a 
number of times in order to collect all of the required new customer information. The 
need for repeating steps 1008 and 1010 is detected, in step 1012. If the customer 
logging in is not a new customer, but if the IMMM detects that additional customer 
information is needed in step 1014, then the IMMM prompts the customer for the 
necessary additional information in step 1016, to which the customer responds in 
step 1018. As in the case of steps 1008 and 1010, depending on the type of 
communications medium through which the customer is connected to the IMMM, 
steps 1016 and 1018 may need to be repeated a number of times, as detected in 
step 1020. When the additional information is collected, if necessary, the routine 
connect to IMMM and login" is complete. 

The need for additional customer information, as detected in step 1014, 
allows the IMMM to continuously update and elaborate information needed to respond 
to the various types of request for quotes forms used by merchants. Thus, if merchants 
require additional information and new forms, or new merchants are found by the 
IMMM with different requirements from previous merchants, the IMMM can make 
deferred additions the information collected from each customer by waiting to collect 
information until the customer again logs in to the IMMM. It is an important feature of 
the IMMM protocol that, whenever possible, the request for quotes forms are filled out 
automatically by the IMMM based on data already resident in the IMMM database. 
This vastly simplifies the customer's interaction with the IMMM in order "to submit 
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request for quotes. The same technique is applicable to basic customer information, 
customer preferences related to specific categories of products or services, and options 
related to specific categories of products and services. Thus, previous selections of 
options can be automatically placed into subsequent request for quotes forms, and the 
customer is given a chance to edit those forms in case the customer selections of options 
have changed over time. These strategies can differ from category to category and may 
be based on predictions from data related to the frequency of chosen, options in 
successive requests for quotes by individual customers, or by a large group of customers 
with respect to any given category. Storage of basic customer data, customer 
preferences, and option selections in the IMMM database is thus an integral facilitator of 
..the easy-to-use interface presented by the IMMM to customers. 

Figure 1 1 is a flow-control diagram of the routine "select category." In 
step 1102, a customer receives a list of categories from the*fi^M. During the first 
iteration of step 1102, the customer generally receives a list of the highest-level 
categories, or the highest-level categories pertaining to some large product or service 
area. When categories are organized in hierarchical fashion, the customer continues to 
select next-lower level categories, in step 1104, from the list of categories provided in 
step 1102 until the desired category level is found, as detected in step 1106. The 
customer then inspects the list of categories to determine if the category that the 
customer is seeking is included. If so, as detected in step 11 08, the user may select the ; 
desired category from the list and return the selected category to the IMMM in 
step 1110, thus completing category selection. If the desired category is not found, then 
the customer can indicate to the IMMM, in steps 1112-11 14, the customer's desire to 
submit requests for quotes to a new category, describe that new category to the IMMM, 
and receive an indication from the IMMM as to whether the new category has been 
coded and enabled. 

This is another important feature that adds flexibility to the IMMM. 
When a customer seeks a new category, the IMMM may, in real time, conduct at least a 
cursory search of various sources of information in order to compile an initial merchant 
list, as well as enter the information concerning the category into the IMMM database. 
If the IMMM can, within a reasonable response time, compile such a list of merchants, 
then the customer can continue with category selection in step 1110. Otherwise, the 
customer may elect, in step 1 1 1 6, to attempt to select a different category. 
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Figure 12 is a flow-control diagram of the routine "input requirements." 
In step 1202, the customer receives a requirements input prompt from the IMMM. In 
step 1204, the customer responds to the prompt in order to input the solicited 
information into the IMMM database. If more requirements are needed by the IMMM, 
as detected in step 1206, steps 1202 and 1204 may be repeated until all the required 
input data is received by the IMMM. In step 1208, the customer receives from the 
IMMM a representation of all the requirements input by the customer. These 
requirements may indicate brands, models, options, color preferences, and any manner 
of information related to the category selected by the customer for which a customer 
desires to receive price quotes. If the customer is not satisfied with the requirements that 
the customer input to the IMMM, as detected in step 1210, the customer may edit the 
input requirements in step 1212 through an editing dialog between the customer and the 
IMMM. Editing of input forms is a.standard type of interactive dialog and will not be 
discussed further. Once the customer is satisfied with the displayed requirements, the 
customer may decide to accept the requirements in step 1214, in which case the 
customer submits an indication of acceptance to the IMMM in step 1216, resulting jrf 
return of the value TRUE by the ratio "input requirements" in step 1222. Otherwise, the 
customer may elect to restart the input requirements dialog, in step 1218, or discontinue 
inputting requirements, resulting in return of the return value FALSE in step 1 220. 

Figure 13 is a flow-control diagram of the routine "receive merchant 
list." In step 1302, the customer receives an initial list of merchants which the IMMM 
has selected from the IMMM database for submission of requests for quotes. The 
customer may then edit this initial list of merchants in step 1304 until the merchant list 
is satisfactory to the customer, as detected in step 1 306. 

Figures 14-20 describe the processing of the basic IMMM transaction 
and transaction protocol by the IMMM. Figure 14 is flow-control diagram that outlines 
IMMM processing. In step 1402, the main processing routine of the IMMM receives a 
new task. IMMM processing is a continuous and ongoing procedure that fields various 
types of requests and tasks from a variety of different sources, including customers, 
merchants, and other IMMM processes or personnel. If the received task is a customer 
connection and login request, as detected in step 1404, the IMMM launches the routine 
"process customer login" in step 1406 in order to conduct the basic transaction outlined 
in Figures 9-13 and discussed above. On the other hand, if the received task is a 
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merchant opt out request, as detected in step 1408, the IMMM processes the merchant 
opt out request by calling the routine "process merchant opt out" in step 1410. Note that 
the merchant is required to login to the IMMM via a login process similar to the login 
process undertaken by customers. That merchant login process is not shown. On the 
other hand, if the received task is an internally generated signal to send out requests for 
quotes, as detected in step 1412, then the IMMM launches the routine "send-out request 
for quotes" in step 1414. Requests for quotes can be sent out periodically via computer 
scans of the IMMM database to detect requests for quotes that have been submitted by 
customers but that either have not yet been submitted to merchants or that were 
submitted at in some threshold period of time before the current time and not yet 
satisfied by the merchants to which the requests were submitted. A number of other, 
strategies for timing the sending out of requests for quotes are possible. If, on the other # 
hand, the received task is an internally generate signal to undertake automated 
surveying, as detected in step 1416, the IMMM launches the routine "send out request 
for feedback" in step 1318 in order to solicit feedback from customers with respect to * 
specific submitted requests for quotes. 

The internal IMMM processing loop, diagrammed in Figure 14, 
continues to iterate in order to handle any outstanding tasks, the need for iteration 
detected in step 1420. If there are not other outstanding tasks, the IMMM may continue 
ongoing building and maintenance of the IMMM database, in step 1422." This isjanother 
important feature of the IMMM. The IMMM is continuously searching for new 
merchants from which to acquire data for the IMMM database. The IMMM, in 
addition, continually monitors for various information sources to determine when forms 
for submitting requests for quotes are changed by merchants so that IMMM database 
tables can be updated to store the new form information. Thus, the IMMM customers 
benefit from extremely comprehensive and thorough pre-compiled information related 
to merchants and to the information required by merchants for submitting requests for 
quotes. It should be noted that many additional types of task may be handled in the 
internal loop represented in Figure 14, including requests for survey information and 
other types of information that is stood in the IMMM database, or that can be compiled 
with reference to the information stored in the IMMM database. 

Figure 15 is a flow-control diagram of the routine "process customer 
login." In step 1502, the IMMM receives a connection request over a particular 
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communications medium and establishes a connection with the customer. In step 1504, 
the IMMM sends a login prompt to the custoiper. In step 1506, the IMMM receives the 
customer's response to the login prompt. In case of certain communications media, such 
as the mail, certain of these steps are not required. As discussed above, the IMMM may 
use SQL-like commands to determine whether the customer is a new customer in 
step 1508. Alternatively, the IMMM may ask the customer at the login prompt to 
indicate whether the customer is a new customer or not. If the customer is a new 
customer, the IMMM, in steps 1510-1512, prompts the customer for new customer 
information and receives the customer's responses, placing the information into the 
IMMM database. As part of this step, a new customer ID must be generated to uniquely-, 
identify the new customer. The information is entered into the IMMM- database in 
step 1414, essentially completing the customer login process and leading to flow of 
control to the routine "get category" in step 1516. If the customer logging in is not a 
new customer, as detected in step 1508, the IMMM uses information furnished by the 
customer to determine the customer's unique ID, as described above, in step 1518. If 
step 1518 fails, as detected in step 1520, then the IMMM increments a bad login counter 
in step 1522 and, providing that the bad login counter has not yet exceeded Sbme 
threshold, as detected in step 1524, begins the login process anew by returning control to 
step 1504. If, on the other hand, the login counter threshold has been exceeded, then the 
IMMM displays a login refusal to the Customer in step 1526 and returns." 

If the customer is properly identified, as detected in step 1520, the 
IMMM determines whether any necessary customer information fields have not been 
previously supplied by the customer, in step 1528, and, if so, solicits that information 
from the customer in steps 1530-1533. The IMMM may detect the need for additional 
customer information by SQL-like commands similar to the following command:. 

SELECT NUMBER FROM customer_varchars 

WHERE cstjd = 2000 AND VALUE = NULL 

NULL values may be placed automatically by the IMMM into uhe 
various customer basic information tables, such as Table 10, discussed above, when 
the IMMM detects new merchants or new merchant forms that require additional 
information, as discussed above. It should be pointed out that the IMMM may be 
selective about the basic information required from customers. For example, in 
certain product or service categories, various merchant forms may differ significantly, 
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and require a large amount of disparate information. In such cases, the IMMM may 
elect to require only a common subset of the various information required by the 
forms up front from customers, and defer soliciting specific information for specific 
forms until such time that the customer selects a merchant using that form* for 
submission of a request for quote. Thus, the IMMM manages a trade off between 
requesting information from customers during initial or subsequent logins, to avoid 
lengthy subsequent submissions of requests for quotes, and asking for too much 
information during the login process that likely may never be used by the IMMM. 

Figure 16 is a flow-control diagram of the routine "get category." In 
step 1602, the IMMM prompts the customer for selection of a next hierarchical 
category level. In step 1604, the EMMM receives a response to the prompt from the 
customer. If the customer selects the next lower level of the hierarchy, as detected in * 
step 1606, the IMMM displays the next lower level categories in step*1608 and waits 
for a response from the customer. There are many possible alternatives for traversing 
a hierarchical organization of categories. Moreover, there are many different types of 
organizations in which categories can be presented to the customer. Thus, initial steps 
for the routine "get category" serve to navigate through some category organization in 
order to display a sublist of categories that include the category that the customer is 
seeking to select, - 

If the customer has found the category that the customer desires, as 
detected in step 1610, the IMMM calls the routine "get input requirements" to 
continue the basic transaction with the customer in step 1612. Otherwise, the IMMM 
conducts a series of steps 1614-1617 in order to determine what new category the 
customer is seeking and create that category within the IMMM database. The creation 
process may involve a real time search of information and sources in order to compile 
a list of merchants that offer a product or service of that category. Alternatively, the 
IMMM may elect to defer compilation of merchant lists to a later time, or may decide 
not to create the new category. 

The IMMM returns an indication to the customer that the new category 
has been created, in step 1620, if the IMMM has elected to create a new category 
along with an initial list of merchants, as detected in step 1618. The IMMM then 
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receives a response from the customer in step 1622 indicating whether the customer 
wishes to select the newly created category. If the customer wishes to select the newly 
created category, as detected in step 1624, the IMMM calls the routine "get input 
requirement" in step 1612 to continue the processing of the customer transaction. 
Otherwise, in step 1626, the IMMM determines whether the customer has indicated a 
desire to select another category, if so, then control flows back to step 1602 to begin 
the category selection process anew. Otherwise, the routine "get category" returns 
without continuing the customer transaction. 

If a new category was not created by the IMMM, the IMMM indicates 
this to the customer in step 1628 and receives a response from the customer, in 
step 1630, indicating whether or not the customer wishes to try selecting another ' 
category. Note that dialogs, such as the category selecting dialog diagrammed in 
Figure 16, may in practice be far more elaborate and allow the customer maiiy 
different options at many different stages in the category selection process. Many 
such dialogs are currently used in automatic telephone answering products, Internet 
web-page based dialogs, and a variety of other technological interfaces. 

Figure 17 is a flow-control diagram of the routine "get input 
requirements." Requirements related to a particular category may be gleaned from a 
number of different sources within the IMMM database. For example, one source of 
such information is Table 14, discussed above. This table lists various information 
related to categories supplied by specific merchants. Thus, the IMMM may use an 
SQL-like command, shown below, to determine that the information field "brand" 
might be a possible requirement for new cars: 

SELECT NAME FROM merchant_category_info 

WHEREcjd = 4 

Alternatively, requirements may be determined by the IMMM from required fields for 
forms, stored in Table 18, for which values cannot be found in either of Tables 10 and 
11 or Tables 16 and 17. The text description of such information can be found by the 
IMMM by executing SQL-like commands such as the command that follows: 
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SELECT query, type FROM forms jiescriptions FC ^ 
WHERE cjd = 4 AND ' * 

( 

(table = 'customerj/archars' AND 
EXISTS 

(SELECT value FROM customer_varchars 
WHERE value = NULL AND cstjd = 2000 
AND num = FD.fieldjd)) OR 
(table = 'customeMnts* AND 
EXISTS 

(SELECT value FROM customerjnte 
WHERE value = NULL AND cstjd = 2000 ' ; : ^ 

AND num = FD.fieldjd)) OR . r 

(table = 'preference^varchars' AND 
EXISTS 

(SELECT value FROM preference_varchars 
WHERE value = NULL AND cstjd = 2000 \ 
AND pjd = FD.fieldjd)) OR 
(table = , preferenceJnts , AND 
EXISTS 

(SELECT value FROM preference jnts 
WHERE value = NULL AND cstjd = 2000 
AND pjd = FD.fieldjd)) 

) - - " 

There are many possible ways that the IMMM can identify requirements to solicit 
from a customer with regard to a particular product or service, in addition to the SQL- 
like commands shown above. 

In step 1702, the IMMM executes one or more SQUike commands to 
extract a list of requirements for which the IMMM needs to solicit values from the 
customer. In step 1704, the IMMM solicits the values for the requirements from the 
customer and, in step 1706, the IMMM receives the solicited values. Step 1704 and 
1706 may be repeated in order to solicit and obtain values for all the requirements 
identified in step 1702. In step 1708, the IMMM displays the requirements for which 
values have been furnished by the customer back to the customer and receives, in 
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step 1710, a response form the customer to the display of requirements. The customer 
may respond by indicating a desire to edit the requirements, as detected in step 1712, 
in which case an editing session is conducted in step 1714. The customer may 
otherwise respond with an indication to accept the requirements as presented in 
step 1708, as detected by the IMMM in step 1716, in which case the IMMM proceeds 
to prompt the customer for contact information, in step 1718, receive the contact 
information and place the contact information into the IMMM database, in step 1720, 
and, finally, call the routine "prepare merchant list", in step 1722. Otherwise, if the 
customer does not wish to accept the requirements as displayed, the customer may 
elect to repeat the transaction, starting with category selection, in which case title 
IMMM calls the routine "get category" in step 1724, or may elect to simply 
discontinue the transaction, in which case the routine "get input requirements" returns 
in step 1726. 

Figure 18 is a flow-control diagram for the routine "prepare merchant 
list." In step 1802, the IMMM determines the desired number of merchants based on 
the category selected by the customer. This desired number of merchants is a 
maximum threshold number so that the list of merchants returned to the customer will 
not exceed the desired number of merchants. The desired number of merchants may 
be determined in any number of ways. The desired number of merchants may be 
solicited from the customer explicitly, may be resident in tte IMMM database as a 
customer preference, or threshold values may be stored in the IMMM database for 
certain types of categories. Alternatively, any combination of these methods and 
many other types of methods can be used by the IMMM to determine this threshold 
value. 

In step 1804, the IMMM extracts an initial list of merchants from the 
database. This can be accomplished by execution of SQL-like commands from which 
the following two commands, which select an initial list of merchants that offer new 
automobiles: 
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CREATE TABLE A (mjd INT, fjd INT); 
INSERT INTOA(mJd,f_id) 

SELECT m_id, fjd FROM merchantjormjist 
WHEREcJd = 4; 

In step 1806, the IMMM determines whether the size of this initial list of merchants, 
computed in step 1804, exceeds the threshold value determined in step 1802. If the 
threshold value is exceeded, the IMMM then repeatedly filters the list, in step 1808, 
based on additional customer preferences or additional requirements until the list of 
merchants falls below the threshold value, or until no more additional preferences can 
be found for additional filtering operations. As an example, the following SQL-like 
statement could be used to filter the initial list of merchants for new cars by customer 
. brand preference. . - 

CREATE TABLE B (mjd INT, fjd INT); 
INSERT INTO B (mjd, fjd) 
SELECT mjd, fjd from A 
WHERE EXISTS 

(SELECT FROM merchan^categoryjnfo M, preference_varchars 
PV, preferences P 

WHERE M.mjd = Amjd AND 
M.name = p.namd AND 
M.cjd = 4AND 
P.cjd =4 AND 
PV.cst = 2000 AND 
PV.p_id = 2000 AND 
PV. value = M.value 

) 

Next, in step 1810, the IMMM filters the list of merchants for geographical proximity, 
as discussed above, in the overview subsection. This filtering can be accomplished by 
inputting the address of the customer and the address of each of the merchants into a 
geographical distance function that computes the distance between the customer and a 
merchant. If the resulting list of merchants is too small, and the radius for considering 
merchants geographically is below some maximum radius, as detected in step 1812, 
the IMMM increases the radius for considering merchants, in step 1814, and then 
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repeats the geographical filtering starting at step 1810. In certain cases, the 
geographical filtering may not be executed by the IMMM. For certain types of 
products or services, geographical filtering may be inappropriate. In other cases, the 
effective radius defining a geographical area of interest may be so large that filtering 
based on other parameters is more appropriate. 

Next, the IMMM determines whether the resulting list of merchants is still 
too large in step 1816. If the list is still too large, and if any additional filtering 
criteria are available, the IMMM carries out an additional filtering in step 1818. In 
step 1820, the IMMM presents a final list of merchants to the customer and receives 
from the customer a response, If the customer's response;: indicates that the customer 
wishes to edit the merchant list, as detected in step 1822, an editing dialog is carried 
; v out by the IMMM in step 1824. Finally, in step 1826, the IMMM calls the routine 

ft • 

''request submission" to complete the IMMM transaction. 

Figure 19 is a flow-control diagram for the routine "quote request 
submission." In step 1902, the IMMM prompts the customer for permission to submit 
requests for quotes to the listed merchants determined in the routine "prepare 
merchant list." In step 1904, the IMMM receives a response from the customer. If 
the customer indicates that the request for quotes should not be submitted, as 
determined in step 1906,- the IMMM determines in step 1908 whether the customer 
wishes to continue the transaction by starting over with selection of a new category . If 
so, then the IMMM calls the routine "get category" in step 1910 to continue 
processing of the transaction. Otherwise, the transaction is ended. If the customer 
elects to submit requests for quotes to the merchant, then the IMMM proceeds by 
processing each merchant in the list of merchants in the for-loop comprising 
steps 1912, 1914, 1916, 1918, and 1920. In step 1914, the IMMM identifies the form 
required by the merchant for the selected category, and, in steps 1916 and 1918, the 
IMMM uses the customer ID, merchant ID, and a newly generated quote ID to 
identify the requests for quotes and enters the information into a row in Table 20, 
Thus, each row of Table 20 represents a submitted request for quote. When all the 
merchants in the list of merchants have been thus processed, the IMMM may, in 
step 1922, present a display indicating that the requests for quotes have been submitted 
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and informing the customer of tracking numbers by which the customer may track the 
requests for quotes as they are processed by the IMMM and merchants. The tracking 
numbers may be the "id" generated in step 1916. 

Figure 20 is a flow-control diagram for the routine "send out requests 
for quotes." In step 2002, the IMMM compares the lastsubmitted and timereceived 
fields of entries in Table 20 to select entries representing requests for quotes that need 
to be submitted either for the first time or submitted again. The IMMM extracts a list 
of merchant ID's from these entries as a list of merchants to which requests for quotes 
need to be sent. One approach for extracting a list of merchants might be to execute 
an SQL-like command such as that which follows: 

SELECT UNIQUE mjd FROM request_fbr_quotes 

WHERE DATEDIFF(week, time received, last submitted) < 2 \V* ; ^ 
AND DATEDIFF(day, lastjsubmitted. GETDATEQ) > 1 / *|jj||>: 
Each merchant in the list is then processed in the for-loop comprising steps 2004, 
2006, 2008, 2010, and 2012. In step 2006, the IMMM extracts completed forms 
from the database for each entry in Table 20 representing a request for quotes that is 
to be submitted. Table 18 lays out forms for requests and indicates where the values 
for each query in the form can be obtained. Forms can be reconstructed from the data 
contained in the IMMM database by execution of a series of SQL-like select 
statements to construct a completed form, as discussed above. Next, in step 2008, the 
IMMM consults Table 12 to determine by what communications medium to submit the 
completed form to the merchant and then submits the form to the merchant in 
step 2008. Then, in step 2010, the IMMM updates the last submitted field in Table 20 
to indicate that the form was submitted. 

Figure 21 is a flow-control diagram showing the merchant processing 
phase of the basic IMMM transaction. In step 2102, the merchant receives a series of 
requests for quotes from the IMMM. In step 2104, the merchant decides whether to 
respond to those requests for quotes, or opt out. If the merchant decides to opt out, in 
step 2106, the merchant decides whether to reply to the IMMM or simply to ignore 
the requests for quotes. If the merchant decides to reply, then in step 2108, the 
merchant replies to the IMMM via a communications medium indicated by the IMMM 
in the package of the requests for quotes submitted to the merchant in step 2102 to 
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indicate that the merchant does not wish to participate at this time. The IMMM can 
then either remove the merchant from the IMMM database, or store information in the 
IMMM database to indicate that the merchant is either temporarily or permanently 
opting out of the IMMM, depending on the merchant's response. This information 
might be stored in additional basic information fields in the logical merchant basic 
information record, represented by Tables 5, 6, and 7. 

If, on the other hand, the merchant decides not to opt out, then the 
merchant processes each request received in step 2102 in the for-loop comprising 
steps 2110, 2112, 2114, and 2116. In step 2112, the merchant determines a price to 
quote for the category of product or service jn the request for quote: '•'•In step 2114, the 
merchant uses information provided in the request for quotes to either respond to the 
IMMM with the determined price quote or respond directly to the customer \yi$^ 
submitted the request for quote. * ' 

Alternative Embodiments and Elaborations 
In the previous three subsections, the basic IMMM customer 
transaction has been described, with reference to a generalized implementation of the 
IMMM database. As noted above, there are almost a limitless number of ways in 
which to define and implement the IMMM database and the processes by which the 
IMMM conducts basic transactions. Many different possible elaborations of the basic 
transaction are possible, including collection and storage of many types of additional 
information, and provision of different options to the customer for submitting, 
directing, and tracking submitted requests for quotes. Quote tracking is made possible 
by the rich information that can be stored in the IMMM database with regard to 
submitted requests for quotes. For example, additional columns can be included in 
Table 20 to indicate stages of processing of a request for quotes within the IMMM and 
within merchant request for quotes processing facilities. Customers can access quote 
tracking tools via the Internet or possibly by telephone to receive information about the 
current status of any particular submitted request for quote. Similarly, rich 
information stored within the IMMM database can form the basis of various request 
for quotes processing tools that can be made available by the IMMM to merchants. A 
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particular benefit to both customers and merchants is that the request for quotes 
information is stored in the centralized database by the IMMM, which may be 
distributed and mirrored and served by redundant, fault-tolerant processes. Thus, 
reliable maintenance of the data is centralized and off loaded from customers and 
merchants. 

In addition to providing the basic IMMM transactions, as discussed 
above, the IMMM can collect survey data from customers and provide the results of 
automated surveys by customers and merchants in order to provide merchant 
verification information to customers and to provide feedback to merchants on the 
service provided by the merchants to customers. The IMMM can use the data stored 
within the IMMM database as a basis for providing any number of additional utilities ' 
and services both to customers and merchants. Merchants may be able to acquire 
comparative information on products and services offered by other Merchants, 
marketing information on the customer population of the IMMM, and other 'such 
useful information. Data collected on the volume of submission of requests for quotes 
and the volume of responses to the requests for quotes can be generated and provided 
to prospective merchants and customers as a marketing tool for the IMMM itself. 

The foregoing description, for purposes of explanation, used specific 
nomenclature to provide a thorough understanding of the invention. However, it will 
be apparent to one skilled in the art that the specific details are not required in order to 
practice the invention. In other instances, well-known components are shown in block 
diagram form in order to avoid unnecessary distraction from the underlying invention. 
Thus, the foregoing descriptions of specific embodiments of the present invention are 
presented for purposes of illustration and description; they are not intended to be 
exhaustive or to limit the invention to the precise forms disclosed, obviously many 
modifications and variations are possible in view of the above teachings. The 
embodiments were chosen and described in order to best explain the principles of the 
invention and its practical applications and to thereby enable others skilled in the art to 
best utilize the invention and various embodiments with various modifications as are 
suited to the particular use contemplated. It is intended that the scope of the invention 
be defined by the following claims and their equivalents: 
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Claims 

I . A method for managing a market transaction between a potential customer 
seeking price quotes on particular product and merchants providing the product, the 
method comprising: 

compiling a database that includes information about products offered by the 
merchants and information about how requests for quotes can be submitted by 
customers to the merchants; 

receiving a request from the potential customer to establish a communications 
connection; 

establishing a communications connection with the potential customer; ; 
when the potential customer is a new customer, * 

receiving from the customer information commonly required by 
merchants from customers seeking quotes and storing the information in the database; 
when the potential customer has previously conducted a market transaction, 

retrieving information related to the customer from the database; 
receiving from the potential customer a selection of a category of product for 
which the potential customer desires quotes; 

selecting from the database a list of merchants offering the selected product; 
for each merchant selected from the list of merchants, 

when additional information related to the selected category is needed in 
order to complete the selected merchant's request for quotes form, 

receiving from the potential customer additional information 
related to the selected category and storing the additional information in the database; 

submitting a request for quotes from the potential customer to 

the selected merchant. 



2. The method of claim 1 wherein the database contains information that 
describes the data required by each merchant described in the database from a potential 
customer in order to provide to the potential customer a quote for a particular product.. 
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3. The method of claim 1 wherein selecting from the database a list of merchants 
offering the selected product further includes: ; ^ 

selecting a list of merchants from the database that provide the selected product 
and that meet any requirements and preferences stored in the database for the potential 
customer; 

when the selected list of merchants is smaller than a threshold number, 
selecting additional merchants from the database by changing the requirements and 
preferences for the potential customer; and 

when the selected list of merchants is larger than a maximum desired number, 
filtering the list of merchants in order to produce a list of merchants no larger than the 
maximum desired number. 

4. The method of claim 1 further including allowing the potential customer to edit 
the selected list of merchants to determine a final list of merchants to which requests for 
quotes are submitted. 

5. The method of claim 1 further including: 

receiving from a merchant to which a request for quotes has been submitted an 
indication that the merchant does not wish to receive requests for quotes, and storing an 
indication in the database to prevent subsequent inclusion of the merchant in selected 
lists of merchants. 

6. The method of claim 1 further including: 

receiving from the potential customer an indication of the potential customer's 
satisfaction with services provided by a merchant to which a request for quotes has been 
submitted on behalf of the potential customer, and storing the indication received from 
the potential customer into the database. 

7. The method of claim 1 wherein products may be tangible goods and services. . 

8. The method of claim 7 wherein compiling the database further includes: 
accessing information sources, such as telephone directories and Internet web 

sites, to identify merchants offering various products; 



WO 00/42547 56 PCT/USOO/01210 

* 

when a description of a product offered by an identified merchant is not 
already present in the database, adding a description of the product to the database; and 

when a description of the merchant is not already in the database, adding a 
description of the merchant to the database. 

■ *■*■ . 

9. The method of claim 8 wherein a description of a product offered" by an 
identified merchant includes a category of product 

10. The method of claim 7 wherein a communications connection may include: 
communications via a telephone connection; 

communications via an exchange of mail through a postal service; 
communications via electronic mail; and 
Internet-based communications via web pages. 

1 1 . The method of claim 7 wherein customer information includes: 
a name; 

an address; 

contact information for various communications media including telephone, 
electronic mail; and 

customer preferences. . 

12. The method of claim 7 wherein additional information related to these lected 
category includes: 

selection of options available for products of the selected category; and 
preferences related to the selected category. 

13. The method of claim 3 wherein selecting from the database a list of 
merchants offering the selected product further includes: 

retrieving the potential customer's preferences and options selected by the- * 
potential customer from the database; 

for each merchant selected from the database that offers the selected product; 
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retrieving the selected merchant's information from the database 
related to the selected category; 

comparing the retrieved preferences and selected options to the 
retrieved information from the database related to the selected category; 

when comparison of the retrieved preferences and selected options 
to the retrieved merchant's information related to the selected category indicates that 
the retrieved preferences and selected options match the retrieved merchant's . 
information at or above a threshold comparison value , 

including the merchant in an intermediate list of merchants; 
for each merchant selected from the intermediate list of merchants, 

calculating a distance between the selected merchant and the potential : 

customer; 

when the calculated distance between the selected merchant and the 
potential customer is less than a maximum value, including the selected merchant in 
the selected list of merchants. 

14. The method of claim 7 wherein submitting a request for quotes from the 
potential customer to the selected merchant further includes: 

retrieving merchant information related to the selected merchant from the 
database; • : 

using the retrieved merchant information to obtain a request for quotes form 
for submitting a request for quotes to the selected merchant; 

retrieving customer information and additional customer information related to 
the potential customer from the database; 

using the retrieved customer information and additional customer information 
to complete the obtained request for quotes form; 

using the retrieving merchant information related to the selected merchant to 
determine a communications medium and communications address to use to submit the 
request for quotes form; and 

sending the completed request for quotes form to the selected merchant. 
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15. A method for submitting requests to quotes for the provision of a good or 
service to a number of merchants by using an intelligent multi-media market, the 
method comprising; 

connecting to the intelligent multi-media market via a communications 

medium; 

logging into the intelligent multi-media market; 

indicating to the intelligent multi-media market a selection of a category of 
good or service for which a quote is desired; 

inputting to the intelligent multi-media market additional information related to 
the selected category of good or service, preferences regarding the selected category of 
good or service, and a selection of options available for the selected "category of good or 
service; . 

receiving from the intelligent multi-media market a list of merchants that 
provide the selected good or server, the provision of the selected good or service by each 
merchant in the list of merchants compatible with the input preferences and selected 
options; 

indicating to the intelligent multi-media market those merchants from the list 
of merchants from which requests for quotes are desired; and 

receiving quotes for the good or service from a number of the selected 
merchants, the requests for quotes having been submitted by the intelligent multi-media 
market to indicated merchants from the list of merchants. 

1 6. The method of claim 1 0 wherein the intelligent multi-media market selects a 
list of merchants that provide the selected good or service from a database of merchants 
compiled by the intelligent multi-media market via information sources available 
through information services such as telephone yellow pages, catalogues, and Internet 
web sites; 

1 7. The method of claim 1 5 wherein a connection to the intelligent multi-media 
market may be made via a telephone connection, the Internet, mail, email, and fax. 

1 8. The method of claim 1 5 wherein logging into the intelligent multi-media 
market further includes: 
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providing identification information to the intelligent multi-media market; and 
when logging into the intelligent multi-media market for the first time, 

providing to the intelligent multi-media market customer information 

commonly required by merchants from customers seeking quotes and storing the 

information in a database; and 

when not logging into the intelligent multi-media market for the first time, 
providing to the intelligent multi-media market additional customer 

information commonly required by merchants from customers seeking quotes and 

storing the information in a database identified by the multi-media market subsequent 

to the last login. 

1 9. The method of claim 1 5 wherein inputting to the intelligent multi-media 
market additional inforrifttion related to the selected category of good or service, 
preferences regarding the selected category of good or service, and a selection of options 
available for the selected category of good or service further includes: 

receiving prompts for additional information related to the selected category of 
good or service, preferences regarding the selected category of good or service, and a 
selection of options available for the selected category of good or service from the 
intelligent multi-media market, the intelligent multi-media market identifying additional 
information related to the selected category of good or service, preferences regarding the . 
selected category of good or service,.and ja selection of options available for the selected 
category of good or service from information contained in the database of information 
related to merchants; 

responding to the prompts for additional information related to the selected 
category of good or service, preferences regarding the selected category of good or 
service, and a selection of options available for the selected category of good or service 
by indicating additional information, preferences, and selections of options to the 
intelligent multi-media market. 

20. The method of claim 1 5 wherein, prior to receiving from the intelligent multi- 
media market the list of merchants, the multi-media market: 

selects an initial list or merchants that provides the selected good or service; 
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filters the initial list of merchants into an intermediate list of merchants based 
on the correspondence between information about merchants stored in the database of 
merchant information and the selected preferences and options; and 

filters the intermediate list of merchants into the list of merchants based on 
geographical location of the merchants. 

21. The method of claim 15 wherein, prior to receiving quotes for the.good or 
service from a number of the selected merchants, the intelligent multi-media market: 

uses customer information, preferences, and selections of options provided to 
the multi-media market to prepare requests for quotes for each indicated merchant! 

sends the prepared requests for quotes- to each of the indicated merchants; 
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